A graphic-based programming tool is an efficient, effective way for a developer to generate executable code while building screens (i.e., user interfaces) because the tool may be used both to create the screen itself, including its graphical items' layout, and to write the program logic behind the screen concurrently. The screen may thus include its layout and its program logic. Such a tool advantageously saves the developer a great deal of time and effort from coding by hand. Therefore, it is important that the graphic-based programming tool perform correctly so that the developer need not expend unnecessary time and effort redoing incorrectly tool-created screens and/or tool-written program logic. Hence, the tool must be tested prior to use.
However, testing such a graphic-based programming tool generally requires a great deal of effort and complexity. One reason is because the testing must be comprehensive so as to test all the ways that a customer will use the tool in the customer's system. Another reason is that screens can be quite complex with many different screen items, where the tool's handling of each item and its interaction with other items in a screen must be tested. Still another reason is that a screen's program logic may include functions shared with other applications on the system, where the tool's coordination of the screen's flow logic and its interaction with other applications in the system must be tested.
Repetitive testing is also required, such as when debugging the graphic-based programming tool. Also where there are shared functions with other applications, repetitive testing is required when the other applications are modified, such as during a software upgrade. Testing must be done to ensure that the upgrade has not changed the program logic of the built screens. When the graphic-based programming tool itself is upgraded, the upgrades must be tested.
For at least these reasons, manual testing is not a viable option to get meaningful and comprehensive graphic-based programming tool testing results.
One solution has been to provide an automated testing approach. FIG. 1 is a block diagram that depicts such an approach. In this approach, a developer may test a graphic-based programming tool using an automatically generated test script made up of test code and hard-coded data. The test code may define the tool's actions and logic and the hard-coded data may include parameter values used by the test code to execute the tool's actions and logic. For example, in FIG. 1, the graphic-based programming tool is a screen builder, which builds screens and concurrently generates program logic executable when the user interacts with the screen. The developer may first use the tool to build Screen 1, which includes the screen's layout and underlying program logic.
During the screen build, a recorder tool may record the tool's actions and data into a test script, such as Test Script 1, to be replayed later to test the graphic-based programming tool. As mentioned previously, the test script may include the test code and hard-coded data. To test the graphic-based programming tool, the developer runs the test script, which automatically causes the graphic-based programming tool to execute the recorded actions. If the rendered screen or the written program logic is incorrect, then the graphic-based programming tool requires correction and re-testing. An error analysis report, for example, Error Analysis 1, may be generated after the test script finishes, indicating where there were errors in the graphic-based programming tool. The developer may edit the graphic-based programming tool to correct any errors and then repeat the test.
This approach advantageously frees the developer of having to manually test the graphic-based programming tool. Rather, the developer need only execute automatically generated test scripts.
This approach works well for a graphic-based programming tool that is unlikely to be upgraded. This is because the program logic, tool actions, and parameter values of the graphic-based programming tool and/or the built screens are unlikely to change. Hence, the test code and the hard-coded data in the test scripts are unlikely to change as well. Therefore, only minor adjustments need be made to the test scripts when testing the graphic-based programming tool using a test screen. Practically, however, most graphic-based programming tools (and other shared applications) are upgraded over time and would not be very useful if they were not. Therefore, it is unlikely that the program logic, tool actions, and parameter values of the graphic-based programming tool and/or the build screens would remain the same.
However, using the approach of FIG. 1 would be problematic for the more practical system in which graphic-based programming tools (and other shared applications) are upgraded over time. For example, since a test script in this approach includes hard-coded data, the entire script must be re-recorded to test the upgraded tool with upgraded test code and/or data, even if the test screen is essentially unchanged. Similarly, since a particular test script may be limited to a particular test screen, test scripts must be recorded for each screen, even when there are only minor changes between the screens. Also, when a screen item and associated program logic are added, deleted, or otherwise modified, all the affected test scripts must be re-recorded. All of these require a great deal of work to test a graphic-based programming tool.
Accordingly, there is a need in the art for an efficient, effective way to automatically test a graphic-based programming tool.